home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 711 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  5.9 KB

  1. From: kuehl@horn.informatik.uni-konstanz.de (Dietmar Kuehl)
  2. Message-ID: <4i882o$7q8@news.BelWue.DE>
  3. X-Original-Date: 14 Mar 1996 04:42:00 GMT
  4. Path: in2.uu.net!bounce-back
  5. Date: 14 Mar 96 14:36:46 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Questions about 'bitset<N>'
  9. Organization: Fakultdt f|r Mathematik und Informatik
  10. Reply-To: dietmar.kuehl@uni-konstanz.de
  11. X-Newsreader: TIN [version 1.2 PL2]
  12. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  13.     iQBFAgUBMUgvYuEDnX0m9pzZAQE3TQF+IvDGF0zDQdAahnTi1HTThhIw4MS+TbKA
  14.     ds+Uzl2kvhwoMVhK3krtjrIIqeFp5D0k
  15.     =SKbv
  16.  
  17. Hi,
  18.  
  19. while looking through the DWP I noticed the class 'bitset' and
  20. investigated the semantics of this class. When doing so, I came across
  21. a couple of strange things which need, IMHO, clarification (or even
  22. modification)... Here is the list of things I noticed appearing strange
  23. or inconsistent to me:
  24.  
  25. 1 The description refers to character values '0' and '1' in various
  26.   places related to the conversion to and from 'basic_string<...>' or
  27.   related to IO.  Although 'basic_string<charT, Traits, Allocator>' is
  28.   used, there is nothing said about a way how to figure out what is '0'
  29.   or '1'. Is it sufficient to assume that '0' is the character literal
  30.   "'0'" and '1' is the character literal "'1'"? ... or is there a need
  31.   for two 'string_char_traits' members called 'zero()' and 'one()'
  32.   returning a corresponding representation? Or is there already such a
  33.   thing and I just missed it...? I can imagine that it could be useful
  34.   to convert strings like "++--+-" or "ttfftf" to 'bitset's (resulting
  35.   in the same value as "110010" would do) or vice versa. This would be
  36.   possible if 'zero()' and 'one()' were defined in the
  37.   'string_char_traits'.
  38.  
  39. 2 The template member 'bitset::to_string()' (note that it doesn't get
  40.   any argument) is declared like this (in the january DWP, which I
  41.   officially don't have...):
  42.     
  43.     template <class charT, class string_char_traits, class Allocator,
  44.           size_t N>
  45.     basic_string<charT, string_char_traits, Allocator>
  46.       bitset<N>::to_string();
  47.   
  48.   Is this really possible? ... and what type is constructed, if it is
  49.   possible, in an expression like this: "bitset<8>().to_string();"?
  50.   The declaration in the April DWP requires a 'string'. Was there too
  51.   much "STL-ization" done in this place?
  52.  
  53. 3 'bitset' appears in the section about containers but it does not
  54.   fullfill the normal container requirements: Why are the normal
  55.   'typedef's missing? Are they just not listed or is the omission
  56.   intentional? Wouldn't it be possible to define at least
  57.   'bitset<N>::value_type' to be 'bool'. The type 'bitset<N>::reference'
  58.   is defined (it is a 'class' in this case) but 'const_reference' is
  59.   not. A reasonable definition could be 'typedef bool const_reference'. 
  60.   This would also enable to add a 'const' subscript operator returning
  61.   a 'const_reference'; currently there is no 'const' subscript
  62.   operator.
  63.  
  64. 4 Why are iterators missing? The following types have to be defined to
  65.   fullfill the requirements for containers:
  66.   - iterator
  67.   - const_iterator
  68.   - difference_type
  69.   - size_type
  70.   None of them is defined for 'bitset<N>'. Also the functions
  71.   - begin()
  72.   - end()
  73.   are missing. As the iterators are likely to be random access iterators,
  74.   if they are added, the functions
  75.   - rbegin()
  76.   - rend()
  77.   together with the necessary iterator 'typedef's would also make sense.
  78.  
  79. 5 'swap()' takes O(N) time (because 'bitset' is intended to use
  80.   built-in arrays as representation instead of memory allocated e.g. on
  81.   the heap).  But since 'N' is part of the input, this is O(1), i.e.
  82.   constant. Why is 'swap()' missing?
  83.  
  84. 6 Why are the relational operators missing? I think that 'false < true'
  85.   holds (I haven't seen a contradicting statement) and this would
  86.   represent the common logic: A 'bitset<N>' can be converted to an
  87.   'unsigned long' (as long as the 'bitset' can be represented as
  88.   'unsigned long' that is). These can be compared with results which
  89.   would be the same if 'bitset' could be compared lexicographically
  90.   with the assumption that 'false < true'.
  91.  
  92. 7 Why are 'max_size()' and 'empty()' missing ('empty()' always
  93.   returning 'false')? These are the only two members missing from
  94.   'bitset<N>' to make it a conforming container (i.e. one which
  95.   fullfills all container requirements), if the other stuff is added.
  96.  
  97. 8 The DWP claims (by the place where bitset is found) that 'bitset' is
  98.   a sequence. This is a lie. The following sequence requirements cannot
  99.   be implemented for 'bitset': 'insert()', 'remove()'. However, when
  100.   stating which containers are seuqences (lib.sequence.reqmts) 'bitset'
  101.   is not listed (this is the truth...).
  102.  
  103. I'm not sure what the state of 'bitset' is... As 'vector<bool,...>' is
  104. a separate class required by the DWP it is well possible that 'bitset'
  105. is the result of a compromise and my suggestions are stretching this
  106. comprise. However, as 'bitset' will apparently become part of the
  107. Standard C++ Library, it should conform to the semantics for other
  108. classes found in the same library. Maybe this stuff can be fixed before
  109. the next public review (I think most, if not all, of these points are
  110. just editorial changes; whether they are wanted is another
  111. question...).
  112.  
  113. Thank you very much for any clarification on the points noted above
  114.   dk
  115.  
  116. BTW, will an overview of the results of the meeting of the
  117. standardization committee posted to this newsgroup? (I think there was
  118. such a meeting very recently...).
  119. --
  120. dietmar.kuehl@uni-konstanz.de
  121. http://www.informatik.uni-konstanz.de/~kuehl
  122. I am a realistic optimist - that's why I appear to be slightly pessimistic
  123. ---
  124. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  125. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  126. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  127. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  128. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  129.